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EXECUTIVE  SUMMARY 


The  purpose  of  this  study  is  to  review  the  existing  computer  resources 
policy  guidance  within  the  Department  of  Defense  and  the  Service  Components 
in  the  light  of  the  newly  issued  Department  of  Defense  Directive  5000.29 
and  to  determine  the  actions  which  should  be  instituted  at  the  Naval  Air 
Systems  Command  (NAVAIR-)  in  order  to  fully  effect  the  policy  stated  therein. 
The  pertinent  policy  and  guidance  documents  prior  to  October  1976  are 
discussed  for  each  of  the  services.  The  current  status  of  computer  resources 
policy  and  guidance  documents  at  NAVAIR  is  presented  and  discussed  as  to 
its  application  in  light  of  policy  set  forth  in  DODD  5000.29. 

The  review  of  existing  Service  Component  policy  guidance  is  of  import- 
ance for  two  reasons.  First,  it  can  be  inferred  from  the  present  situation 
why  DODD  5000.29  was  promulgated.  An  obvious  finding  is  the  lack  of 
uniformity  across  and  within  the  Service  Components  with  regard  to  the 
management  of  weapon  systems  computer  resources  and  the  rising  costs 
associated  thereto.  Secondly,  the  review  provides  a source  of  new  ideas 
for  consideration  in  the  updating  of  NAVAIR' s existing  guidance  documents. 

Specific  recommendations  are  presented  which  if  implemented  at  NAVAIR 
would  promulgate  the  policy  set  forth  in  DODD  5000.29  for  Navy  airborne 
weapon  systems  computer  resources. 
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SECTION  I 


INTRODUCTION 

Purpose 

The  purpose  of  this  study  is  to  assess  the  impact  of  Department  of 
Defense  Directive  (DODD)  5000.29,  "Management  of  Computer  Resources  in 
Major  Defense  Systems",  on  the  Naval  Air  Systems  Command  (NAVAIR) . DODD 
5000.29  establishes  policy  for  the  management  and  control  of  computer 
resources  during  the  development,  acquisition,  deployment  and  support  of 
major  Defense  systems  (12:1)^".  DODD  5000.29  was  dated  and  became  effective 
on  26  April  1976.  As  of  the  date  of  this  report,  no  Secretary  of  the  Navy 
Instruction  (SECNAVINST) , Naval  Material  Command  Instruction  (NAVMATINST) , 
or  Naval  Air  Systems  Command  Instruction  (NAVAIRINST)  had  been  promulgated 
which  specifically  implements  DODD  5000.29. 


Goals 

The  goals  of  this  report  are  to  determine  what  steps  and  actions  should 
be  taken  at  NAVAIR  in  order  that  timely  compliance  with  DODD  5000.29  is 
achieved.  The  effect  of  achievement  of  these  goals  will  result  in 
reliable  computer  resources  being  acquired  which  meet  the  mission  require- 
ments for  Navy  airborne  weapon  systems  at  minimum  life  cycle  costs. 


This  notation  will  be  used  throughout  the  report  for  sources  of 
quotation  and  major  references.  The  first  number  is  the  source 
listed  in  the  bibliography.  The  second  nu  ber,  if  listed,  is  the 
page  in  the  reference  from  which  the  quotation  or  reference  was 
taken. 


Definitions 


The  following  definitions  have  been  utilized  in  this  report: 

Computer  Data.  Basic  elements  of  information  used  by  computer  equip- 
ment in  responding  to  a computer  program. 

Computer  Equipment.  Devices  capable  of  accepting  and  storing  computer 
data,  executing  a systematic  sequence  of  operations  on  computer  data  or 
producing  control  outputs.  Such  devices  can  perform  substantial  inter- 
pretation, computation,  communication,  control,  and  other  logical  functions. 

Computer  Program.  A series  of  instructions  or  statements  in  a form 
acceptable  to  computer  equipment,  designed  to  cause  the  execution  of  an 
operation  or  series  of  operations.  Computer  programs  include  such  items 
as  operating  systems,  assemblers,  compilers,  interpreters,  data  management 
system,  utility  programs,  and  maintenance/diagnostic  programs.  They  also 
include  application  programs  such  as  payroll,  inventory  control,  opera- 
tional flight,  strategic,  tactical,  automatic  test,  crew  simulator,  and 
engineering  analysis  programs.  Computer  programs  may  be  either  machine 
dependent  or  machine  independent,  and  may  be  general  purpose  in  nature  or 
be  designed  to  satisfy  the  requirements  of  a specialized  process  of  a 
particular  user. 

Computer  Resources.  The  totality  of  computer  equipment,  computer 
program,  computer  data,  associated  documentation,  personnel,  and  supplies. 

Computer  Software.  A combination  of  associated  computer  programs 
and  computer  data  required  to  enable  the  computer  equipment  to  perform 
computational  or  control  functions. 


m . 


%n 


Embedded.  Adjective  modifier;  integral  to,  from  the  design,  pro- 


curement, and  operations  point  of  view  espoused  in  DOD  Directive  5000.1. 

Software  Engineering.  Science  of  design,  development,  implementation, 
test,  evaluation,  and  maintenance  of  computer  software  over  its  life  cycle. 

Scope 

This  report  will  be  limited  to  determining  the  management  approach 
and  management  tools  which  should  be  utilized  by  NAVAIR  in  the  management 
of  computer  resources  for  both  major  Defense  systems,  as  set  forth  in 
DODD  5000.1,  "Acquisition  of  Major  Defense  Systems",  and  less  than  major 
Defense  systems  (11).  DODD  5000.29  sets  forth  the  responsibilities  of  the 
Department  of  Defense  (DOD)  Components  to  (1)  review  their  existing 
regulations,  specifications,  and  standards  with  the  purpose  of  modifying, 
cancelling,  or  supplementing  them  as  required  to  ensure  consistency  with 
the  policy  of  DODD  5000.29  and  (2)  develop  and  implement  a disciplined 
approach  to  the  management  of  software  design,  engineering,  and  programming 
which  will  ensure  the  provision  of  effective  software  at  minimum  life 
cycle  cost  (12:4) . 


Limitations 

The  report  is  limited  to  the  responsibility  set  forth  at  the  Naval 
Material  Command  (NMC)  for  the  Tactical  Digital  Systems  Office  (TADSO), 
MAT-09Y,  and  at  NAVAIR  for  the  Director  of  the  Avionics  Division  (AIR-533) 
and  the  Computer  and  Software  Branch  (AIR-5331)  for  the  implementation  of 
policy  set  forth  in  DODD  5000.29.  DODD  5000.29  specifically  excludes 
from  its  provisions  the  general  purpose,  commercially  available  automatic 
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data  processing  (ADP)  assets  which  are  administered  under  OMB  Circular 
A-71,  DODD  4105.55,  4160.19,  and  5100.40  references  (37),  (9),  (10),  (11), 
and  (13)  respectively.  DOD  5000.29  does  state: 

....where  feasible,  the  terms,  tools,  and  techniques  employed  in 
the  general  purpose  area  will  be  adopted  or  adapted  to  support  manage- 
ment of  computer  resources  in  major  Defense  systems  (12:1). 

TADSO's  responsibility  does  not  include  policy  formulation  and 

application  aspects  of  strategic,  automatic  test,  business  and  logistics 

systems;  but  does  include  interface  between  such  systems  and  tactical 

systems  (33:1).  AIR-533  responsibility  is  limited  to  weapon  system 

tactical  digital  processors  and  related  software  (28:2).  The  report 

therefore  will  not  address  in  detail  digital  computer  utilized  in  automatic 

test  equipment  (ATE)  or  trainers. 

Organization  of  the  Report 

The  report  is  organized  such  that  a case  is  built  for  the  conclusions 
and  recommendations  presented  in  Section  VI.  Section  II  discusses  the 
collection  of  data  and  how  it  was  used  in  arriving  at  the  author's 
recommendations.  Section  III  presents  the  history  of  DODD  5000.29  and 
discusses  the  studies  and  analysis  leading  up  to  its  issuance.  Examples 
are  presented  to  show  some  of  the  problems  which  have  and  are  being 
experienced  in  the  development  and  acquisition  of  software.  Section  IV 
sets  forth  the  existing  policy  and  guidance  documents  being  utilized  at 
NAVAIR  and  discusses  two  new  documents  being  prepared.  Section  V analyses 
and  compares  computer  resources  policy  and  guidance  documents  which  exist 
for  the  service  components.  Military  Standards  (MIL-STDs)  and  Military 
Specifications  (Mil-SPECs)  that  are  applicable  to  software  acquisition 
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are  discussed.  Section  VI  sets  forth  the  author’s  conclusions  and 
recommendation  as  to  what  new  computer  resources  policy  and  guidance 
documents  should  be  implemented  at  NAVAIR. 


SECTION  II 


DATA  COLLECTION  AND  ANALYSIS  METHOD 

The  methodology  used  to  perform  this  study  is  based  on  the  author’s 
knowledge  of  the  tactifcal  computer  and  software  efforts  at  NAVAIR  over 
the  past  five  years  and  discussions  with  Navy  tactical  software  personnel 
at  NMC  and  NAVAIR.  Applicable  computer  resources  policy  guidance  documents 
for  the  Service  Components  were  collected  and  analyzed  as  to  compliance 
with  DODD  5000.29  and  as  a source  of  ideas  for  use  in  preparing  new 
guidance  at  NAVAIR.  Recent  software  acquisition  reports  and  studies  were 
analyzed  in  the  hopes  of  finding  new  methods  and  approaches  for  imple- 
menting better  software  management  technique.  Existing  MIL-STDs  relating 
to  the  management  of  computer  resources  are  reviewed  and  discussed  since 
some  are  approved  and  are  mandatory  for  use  by  all  Departments  and  Agencies 
of  the  Department  of  Defense  and  others  are  approved  only  for  use  by  a 
given  service  component. 


I 
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SECTION  III 


HISTORY  OF  DOD  DIRECTIVE  5000.29 
Background 

The  need  for  DODD  5.000.29  is  appropriately  summarized  in  the  Office 
of  the  Assistant  Secretary  of  Defense,  Installations  and  Logistic,  cover 
letter  for  the  DOD  Defense  System  Software  Management  Program  of  March  1976 
which  states: 

The  sharply  rising  costs  of  software  programs  in  the  Defense 
system  acquisition  process,  with  respect  to  acquisition  procedures, 
development  and  maintenance  of  such  software,  and  the  increasing 
importance  of  the  software  roles  in  the  overall  mission  effectiveness 
of  major  Defense  Systems  constitute  serious  technical  and  management 
problems  that  must  be  solved  if  we  are  to  have  the  Defense  Systems 
that  are  needed  for  our  national  security  (6:i). 

These  same  words  were  essentially  used  in  the  3 December  1974 

memorandum  issued  by  the  Assistant  Secretaries  of  Defense  (Installations 

and  Logistics  and  Comptroller)  and  the  Director  of  Defense  Research  and 

Engineering  which  initiated  a two  phase  study  program  into  the  area  of 

management  of  weapon  systems  software  (36:1). 

The  weapon  systems  of  today  are  very  complex  and  consist  of  many 

integrated  subsystems  many  of  which  are  controlled  by  digital  computers 

and  their  associated  computer  software.  The  Department  of  Defense  and 

the  Service  Components  have  many  policies,  regulations,  procedures, 

Military  Standards  (MIL-STDs)  and  Military  Specifications  (Mil-SPECs) 

which  deal  with  the  acquisition  and  management  of  military  hardware; 

however,  very  few  of  these  are  applicable  to  computer  software.  The 

results  are  that  serious  technical  and  management  problems  do  indeed 


exist  as  is  evidenced  by  sharply  rising  life  cycle  costs  of  software 
programs. 

The  PMC  76-1  Study  Project  Report  by  Mr.  Pontius  is  recommended  as  a 
source  of  information  concerning  life  cycle  guidelines  for  weapon  system 
software  management  (38).  Mr.  Pontius  provided  a strategic  level  exposure 
to  problems  inherent  in  the  management  of  computer  software  and  highlighted 
key  documents  which  have  been  promulgated  and  resulted  in  top  management 
in  both  DOD  and  the  Service  Components  becoming  more  aware  of  the  lack 
of  controls  on  and  the  rising  costs  of  weapon  system  software. 

The  October  1975  issue  of  the  Defense  Management  Journal  was  dedicated 
to  DOD  weapon  system  software  articles  (8).  The  "Comment"  section  by 
Mr.  Gansler,  Deputy  Assistant  Secretary  of  Defense  (Material  Acquisition), 
OSAD(I&L),  inforces  the  growing  awareness  of  the  software  problem  and 
stated: 

In  recent  months,  managers  in  Defense  and  industry  have  been 
challenged  by  three  important  weapon  systems  issues:  the  lack  of 
sufficient  control  over  rapidly  growing  software  expenditures,  the 
lack  of  sufficient  research  and  development  in  software  production, 
and  the  need  for  major  improvements  in  weapon  systems  software 
management  (8:1). 

An  excellent  paper  which  presents  the  history  of  digital  computers 
in  weapon  systems  was  prepared  by  Mr.  Zempolich  while  a student  at  the 
Industrial  College  of  the  Armed  Forces  and  provides  an  analysis  of 
computer  software  management  for  operationally  deployable  systems  (48). 

The  research  for  the  paper  was  performed  in  the  June  1973  to  February  1974 
time  frame.  The  paper  is  recommended  as  a source  of  information  and 
references  for  the  reader  desiring  additional  depth  into  the  software 
management  problem  from  a historical  point  of  view.  As  a note  of  interest, 


Mr.  Zempolich  was  the  original  section  head  at  NAVAIR  for  the  group  of 
people  destined  to  become  the  Computer  and  Software  Branch  (AIR-5331). 

POD  Directive  5000.29 

DOD  Directive  5000.29  sets  forth  the  DOD  policy  for  the  management 
and  control  of  computer  resources  during  the  development  and  support  of 
major  Defense  systems  (12).  The  policies  set  forth  cover  the  areas  of: 

1.  General  management  policy 

2.  Validation  and  Risk  Analysis 

3.  Configuration  Management 

4.  Life  Cycle  Planning 

5.  Support  Software  Deliverable 

6.  Milestone  Definition  and  Attainment  Criteria 

7.  Software  Language  Standardization  and  Control 

The  directive  established  a Management  Steering  Committee  for  Embedded 
Computer  Resources  to  oversee  and  coordinate  the  incorporation  of  its 
policies  and  principles  into  the  normal  Defense  systems  acquisition  pro- 
cess. The  directive  further  required  the  Service  Components  to  review  and 
modify  or  supplement  existing  regulations  and  procedures  to  ensure 
consistancy  with  the  policy  set  forth. 

The  Defense  System  Software  Management  Plan  of  March  1976  sets  forth 
the  DOD  Software  Management  Steering  Committee's  detailed  plan  for  the 
solution  of  DOD  computer  resources  management  problems  (6).  The  plan 
sets  forth  the  actions  and  responsibilities  of  the  organizations  involved 
in  implementing  the  requirement  of  DODD  5000.29. 

DOD  Studies  and  Reports 

The  Office  of  the  Secretary  of  Defense  Memorandum  of  3 December  1974 
established  the  DOD  Software  Steering  Committee  to  oversee  a coordinated 
and  joint  study  by  the  Applied  Physics  Laboratory  (AJL)  at  John  Hopkins 
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University  and  the  Mitre  Corporation  (36).  Each  was  to  conduct  separate 
but  coordinated,  four  month  studies  to  identify  and  define: 

(1)  the  nature  of  the  critical  software  problems  facing  the  DOD, 

(2)  the  principal  factors  contributing  to  the  problems, 

(3)  the  high  pay-off  areas  and  alternatives  available,  and 

(4)  the  management  instruments  and  policies  that  are  need  to  define 
and  bound  the  functions,  responsibilities  and  mission  areas  of 
weapon  systems  software  management  (36:1). 

The  second  phase  of  the  study  was  an  indepth  study  into  the  critical 
areas  identified  in  the  four  month  study  period.  The  results  of  these 
studies  and  the  recommendations  of  the  DOD  Software  Steering  Committee 
resulted  in  the  promulgation  of  DODD  5000.29. 

The  APL  study  set  forth,  under  seven  categories,  specific  actions 
which  should  be  taken  to  attack  many  of  the  problems  encountered  in  the 
software  development  and  support  area.  The  seven  categories  were  (1) 
Management  Policy,  (2)  Acquisition  Planning,  (3)  System  Engineer,  (4) 
Implementation  Procedures,  (5)  Program  Management  Support,  (6)  Acquisition 
Management  Standards,  and  (7)  Development  Task  and  Techniques  (15:2-1). 
Table  6-1  presented  on  page  6-3  of  the  report  provides  a matrix  showing 
direct  and  indirect  correlations  between  the  recommendations  set  forth 
under  the  seven  categories  listed  above  and  the  problem  area  in  each  of 
the  five  phases  of  the  acquisition  life  cycle  as  seen  by  APL.  Figure  1-1 
on  page  1-3  of  the  report  sets  forth  the  same  problems  in  the  form  of  a 
life  cycle  flow  diagram. 

The  Mitre  study  set  forth  four  high  payoff  areas  which  should  be 
addressed  by  DOD.  The  four  areas  were  (1)  software  performance  specifi- 
cation, (2)  software  acquisition  planning,  (3)  software  technology,  and 
(4)  personnel  (14:xiii).  Mitre  recommended  the  review  of  software 
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earlier  in  the  Defense  Systems  Acquisition  Review  Council  (DSARC)  process, 
the  consistent  application  of  sound  engineering  principles,  the  need  for 
complete  software  specifications,  the  establishment  of  a coordinated 
software  technology  program,  and  the  need  for  a consistent  framework  and 
definition  of  recommended  software  management  practices. 

The  reports  of  both  studies  are  recommended  for  indepth  study  since 
prior  software  studies  are  reviewed  and  summarized.  The  bibliography 
to  the  APL  study  contains  three  hundred  fifty  seven  references. 

Mr.  DeRoze,  Directorate  for  Weapons  Support  Systems  Acquisition, 
OSD(I&L),  summarized  the  results  of  the  APL  and  MITRE  studies  in  his 
article  "An  Introspective  Analysis  of  DOD  Weapon  System  Software  Manage- 
ment". Mr.  DeRoze' s article  set  forth  the  areas  which  were  to  become 
DOD  5000.29  policy.  Mr.  DeRoze  summarized  the  problem  areas  as  follows: 

(1)  Visibility  in  weapon  system  acquisition 

* Inadequate  requirements  analysis 

* Inadequate  interface  management 

* Inadequate  documentation 

* Lack  of  transferability 

* Inaccurate  cost/schedule  projections 

* Low  quality 

(2)  Language  selection 

* Low  correlation  of  machine-oriented  language  to  engineering 
problems 

* Lack  of  design  visibility 

* Machine  dependance 

(3)  Language  proliferation 

* Difficult  learning  process 

* Discourages  development  of  test  and  support  equipment 

* Reduces  management  visibility 

* Complicates  institutional  control 

* Cost  reduction 

(4)  Quality  assurance  and  control 

* Lack  of  management  monitoring  of  software  reliability 

* Lack  of  software  reliability  quality  assurance  disciplines 

* Lack  of  quantitative  data  base 


(5)  Lack  of  software  acquisition  management  standards 

* Terminology 

* Directives,  instructions,  standards 

(6)  Lack  of  acquisition,  management,  operations  and  support  guideline 

(7)  Lack  of  formal  personnel  development  and  training 

(8)  Research  and  development 

* Lack  of  focus 

* Relevancy 

* Lack  of  technology  base 

* Redundancy  and  duplication  (8:6) 

A major  study  which  has  influenced  DOD  is  the  "Findings  and  Recommend- 
ations of  the  Joint  Logistics  Commanders  Software  Reliability  Work  Group 
(SRWG  Report)  of  November  1975.  The  report  documents  over  a year's  work 
by  30  computer  software  professionals  from  DOD,  industry,  and  the  academic 
community.  Of  particular  interest  is  the  follow  statement  from  the  report: 

Soon  after  initiating  their  investigation  into  the  software 
reliability  question,  the  Software  Reliability  Work  Group  (SRWG) 
found  it  necessary  to  address  the  much  broader  area  of  computer 
resource  acquisition  for  military  systems  (17 :i). 

The  detailed  finding  and  recommendations  of  the  SRWG  are  set  forth 
under  the  following  recommendations  categories:  (1)  change  in  policy  and 
procedure,  (2)  software  reliability  improvement,  (3)  management  procedures, 
(4)  changes  in  technical  training  and  technology  improvement,  (5)  establish- 
ment of  a new  capability,  (6)  reliability  improvement  program,  and  (7) 
changes  in  policies  at  the  OSD  level,  procedures  at  the  DOD  and  component 
service  levels  and  a reliability  improvement  program  are  necessary.  The 
SRWG  findings  and  recommended  solutions  are  embodied  in  DODD  5000.29. 

Navy  Studies  and  Reports 

The  MUDD  Report  written  by  Mr.  Weiss  of  the  Naval  Research  Laboratory 
(NRL)  in  May  1975  presents  milestones  in  the  development  of  a fictional 
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software  development  program  of  a Navy  weapons  system.  The  fictional 
narrative  prepared  by  Mr.  Weiss  is  well  worth  reading  since,  in  a 
humorist  way,  he  presented  real  world  software  development  and  acquisition 
problems  which  have  been  encountered  in  the  Navy.  Of  particular  import- 
ance are  the  recommendations  he  presented: 

* Unify  life-cycle  control  of  software. 

* Require  the  participation  of  experience  software  engineers  in  all 
system  decisions. 

* Require  the  participation  of  system  users  in  the  development  cycle 
from  the  time  requirements  are  established  until  the  time  the 
system  is  delivered. 

* Write  acceptance  criteria  into  software  development  contracts. 

* Develop  software  on  a system  that  provides  good  support  facilities. 

* Design  software  for  maximum  compatibility  and  reusability. 

* Allocate  development  time  properly  among  design,  coding,  and 
checkout . 

* List,  in  advance  of  design,  all  areas  in  which  requirements  are 
likely  to  change 

* Use  state-of-the-art  principles,  such  as  information  hiding. 

* Critical  design  reviews  should  be  active  reviews  and  not  passive 
tutorials. 

* Do  not  depend  cn  progress  reports  to  know  the  state  of  the  system. 

* Require  executable  milestones  that  can  be  satisfactorily  demonstrated. 

* Ensure  that  a proper  variety  of  test  data  is  used. 

* Maintain  current,  complete  documentation  (46:25  thru  28). 

The  recommendation  of  Mr.  Weiss  are  typical  of  the  areas  which  should 
be  expanded  and  incorporated  into  appropriate  service  guidance  documents 
as  required  by  paragraph  VI,  C,  1 of  DODD  5000.29  (12:4). 

In  the  25  June  1974  Memorandum  of  Mr.  Potter,  Assistant  Secretary  of 
the  Navy  (R&D),  he  stated  that: 

There  currently  is  no  formal  or  structured  program  for  software 

research  and  development  within  the  Navy An  endeavor  that 

holds  promise  in  increasing  the  efforts  of  software  research  and 
development  in  the  recently  formal  Department  of  Defense  Software 

Committee The  Navy  has  recently  formed  a Laboratory  Computer 

Committee,  comprised  of  representatives  from  the  Navy's  research  and 
development  activities,  which  will  aid  the  efforts  of  the  Department 
of  Defense  Software  Committee  (7:1). 
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The  Navy  Laboratory  Computing  Committee  has  produced  two  reports, 
the  Operational  Software  Panel  Report  dated  September  1975  (39)  and  the 
Software  Technology  R&D  Panel  Report  dated  September  1976  (40).  The 
Operational  Software  Panel  presented  Navy  software  problems  and  provided 
recommendations  for  their  solution.  Twenty-three  (23)  problem  areas  were 
set  forth.  Some  of  the  more  critical  problem  areas  include: 

* Software  inadequately  addressed  in  the  definition  of  system 
development  requirements 

* Nonstandardization  of  hardware  and  software 

* Incomplete  software  life  cycle  planning 

* Nonuniform  management  practice  (Navy  and  developer/contractor) 

* Poor  performance  monitoring  by  management 

* Poor  utilization  of  corporate  memory 

* Inadequate  contract  specification  for  software 

* Inadequate  testing 

* Poor  quality  assurance 

* Inadequate  documentation 

* Insufficient  personnel  training 

* Underestimation  of  support  cost  with  consequent  need  for 
supplementory  funding 

* Lack  of  feedback  (developer  - user  interaction)  (39:13,  14,  15) 

The  panel's  recommendations  stressed  (1)  the  need  for  management 

procedures  that  address  cost-effective  and  timely  preparation  for 
operational  support  of  system  software,  (2)  the  need  for  a Navy  Laboratory 
or  other  in-house  activity  to  be  actively  involved  in  major  Navy  software 
efforts,  and  (3)  the  need  for  software  technology  R&D  efforts  on  a board 
front  in  areas  such  as  software  reusability,  design,  error  classification, 
standards,  and  specifications. 

The  software  Technology  R&D  Panel  similiarly  discussed  Navy  software 
problem  areas  and  concluded  that  there  was  a common  set  of  software 
problems  in  the  areas  of  command-control,  weapon  systems,  logistics,  and 
general  scientific  including  computer-aided  design  (40:3).  The  panel 
recommended  a five  year  52.6  million  dollar  program  to  be  centrally 
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managed  by  Chief  of  Naval  Technology  (MAT-03T)  in  the  area  of  research 
initiatives  and  the  exploitation  of  developing  research  results  for 
software  technology  (40:4.5). 

A draft  NMC  R&D  Program  for  the  Management  of  Computer  Resources  in 
Navy  Systems,  dated  7 September  1976,  has  been  prepared  by  the  Naval 
Sea  Systems  Command  (34).  The  draft  plan  expands  an  original  draft 
prepared  and  forwarded  on  20  August  1976  by  MAT-03Y  to  the  Navy  System 
Commands.  The  plan  sets  forth  a proposed  NAVMAT  Computer  Sciences  R&D 
Council  to  assist  the  Chief  of  Naval  Material  (CNM)  in  managing  a 


coordinated  6.1  thru  6.4  R&D  funds  expenditure  to  development  and  transi- 
tion software  system  design  and  development  methodologies  into  tools  and 
technologies  which  will  aid  managers,  designers,  developers,  and  main- 
tainers  in  solving  existing  computer  resource  problems.  The  time  frame  for 
the  efforts  are  from  FY  78-82  with  individual  efforts  running  from  one  to 
five  years  depending  on  the  particular  task  area. 

Industry  Studies  and  Reports 

An  active  group  on  the  industry  side  of  the  computer  resources  problem 
in  DOD  is  the  Electronic  Industries  Association,  G-33  Data  and  Configuration 
Management,  Committee's  Computer  Software  Task  Group  (16).  The  Electronic 
Industries  Association  is  composed  of  members  of  industry  who  are  DOD 


contractors  and  are  therefore  extremely  interested  in  DOD  and  Service 
Components  regulations,  policy,  MIL-STD's,  and  MIL-SPEC's.  The  minutes  of 
the  27  July  1976  session  of  the  Computer  Software  Task  Group  reflect  that 


appendices  relating  to  B5  and  C5  Computer  Software  Specifications  in 
MIL-STD-490  (22). 


SECTION  IV 


REVIEW  OF  PRESENT  SITUATION  AT  NAVAIR 
General  Description 

The  Director  of  the  Avionics  Division  (AIR-533)  is  responsible  for  the 
management  of  all  weapon  system  tactical  digital  processors  and  related 
software  at  NAVAIR.  The  Computer  and  Software  Branch  (AIR-5331)  attends 
to  the  day-to-day  operations  and  interface  with  the  NAVAIR  program  managers. 
The  personnel  in  AIR-5331  are  electronic  engineers  and  computer  specialists 
with  indepth  knowledge  and  experience  in  real  time  tactical  digital  computer 
systems.  To  date  the  success  of  the  branch  has  greatly  depended  on  the 
informal  organization  and  strength  of  the  people  in  the  branch.  True 
policy  guidance  in  the  form  of  NAVMATINSTs  or  NAVAIRINSTs  is  lacking  at 
NAVAIR;  however,  certain  new  documents  are  being  prepared. 

Timely  management  of  NAVAIR' s embedded  computer  resources  has  been  a 
prime  concern  of  the  Computer  and  Software  Branch  since  its  formation  in 
the  summer  of  1974  by  the  Direction  of  the  Avionics  Division.  Prior  to 
1974  the  people  who  now  compose  the  Computer  and  Software  Branch  were  a 
section  within  the  Radar  Branch  of  the  same  division.  The  organization 
required  to  effect  timely  management  of  computer  resources  therefore  really 
did  not  exist  prior  to  1974.  With  the  promulgation  of  DODD  5000.29,  the 
necessary  top  level  DOD  interest  has  been  set  forth  and  the  mission  of 
people  at  the  functional  levels  with  NAVAIR  in  accomplishing  timely 
management  of  computer  resources  has  been  greatly  stengthen. 

In  order  to  assess  the  current  situation  at  NAVAIR,  the  applicable 
computer  resources  related  NAVAIR  instructions  and  guidance  documents 


17 


will  be  presented  and  analyzed. 


AR-59B 

The  NAVAIR  Aeronautical  Requirement,  AR-59B,  "General  Management 
Requirements  for  Project  Management",  dated  1 May  1972,  sets  forth  a 
PROMPT  Guide.  PROMPT  stands  for  project  reporting,  organization,  and 
management  planning  techniques  and  constitutes  an  inventory  of  management 
requirement  which  may  be  applied  to  a project.  The  NAVAIR  Project  Managers 
can  use  the  PROMPT  Guide  as  a shopping  list  from  which  they  can  select 
those  requirements  most  closely  statisfying  their  project's  management 
needs.  The  PROMPT  Guide  is  applicable  to  all  major  programs  as  set  forth 
in  DOD  Directive  5000.1  and  may  be  used  in  establishing  management  require- 
ments for  programs  or  projects  of  lesser  magnitude. 

Several  observations  can  be  made  concerning  AR-59.  It  was  issued  in 
May  1972  and  is  in  need  of  being  updated.  It  does  not  adequately  set 
forth  the  acquisition  management  guidance  which  the  NAVAIR  Program  Manager 
should  consider  in  managing  a major  weapon  system.  The  only  guidance  given 
the  Program  Manager  in  the  software  area  is  a sample  definition  under  the 
Work  Breakdown  Structure  paragraph  (5:10). 

MIL-D-8706B (AS) 

This  NAVAIR  military  specification  sets  forth  the  engineering  data 
and  tests  requirement  which  may  be  invoked  on  a NAVAIR  contract  for 
aircraft  weapon  systems.  The  specification  covers  airframe  requirement 
and  Contractor  Furnished  Equipment  (CFE).  The  required  data  is  set  forth 
on  a DD  Form  1423  which  is  part  of  the  airframe  contract.  The  only 
reference  made  to  computer  program  data  is  that  for  a report  outlining 
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the  planned  program  for  use  of  digital  and  analog  computers  used  in 
analytically  simulating  the  airplane  response  characteristics  (18:4). 


Several  observations  can  be  made  concerning  MIL-D-8706B(AS) . The 
specification  was  last  updated  on  15  August  1968  and  does  not  include 
appropriate  software  data  requirements.  The  data  requirements  should  not 
be  specified  in  a military  specification;  but  should  be  set  forth  in 
standard  Data  Item  Descriptions  (DIDs)  since  this  is  the  DOD  approach 
which  should  follow  when  acquiring  data  under  a contract. 


NAVAIRINST  5230. 3A 


This  NAVAIR  instruction  requires  that,  as  of  March  1975,  software 
documentation  standards  set  forth  in  SECNAVINST  3560.1  be  required  in  all 
contracts  requiring  the  delivery  of  digital  processor  programs.  Prior  to 
March  1975,  Weapon  Specification  WS-8506  was  utilized  as  the  software 
documentation  standard.  SECNAVINST  3560.1  and  WS-8506  are  discussed  in 
Section  V of  this  report. 

In  the  background  paragraph  of  NAVAIRINST  5230. 3A,  it  is  stated: 

Documentation  of  digital  processor  programs  has  frequently  been 
inadequately  specified  in  contracts,  thereby  adversely  affecting  the 
quality  of  the  program  delivered.  The  lack  of  adequate  documentation 
results  in  digital  processor  programs  which  are  poorly  designed, 
improperly  implemented,  inadequately  tested,  and  inordinately  difficult 
to  manage  (27:1) . 

The  statement  is  appropriate  since  the  software  documentation  standards 
which  are  invoked  includes  specifications,  test  plans  and  procedures,  and 
manuals  required  for  operating  and  maintaining  the  software  program  being 

procured. 
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NAVAIRINST  5230.4 

This  NAVAIR  instruction  was  promulgated  on  1 August  1974  and  assigns 
responsibility  for  the  management  of  all  weapon  system  tactical  digital 
processors  and  related  software  to  the  Director  of  the  Avionics  Division 
(AIR-533)  (28:2).  The  instruction  requires  that  cognizant  program  managers 
budget  for  and  provide  to  AIR-533  sufficient  funding  to  enable  him  to 
properly  manage  the  weapon  system  computer  resources.  AIR-533' s respon- 
sibility includes  planning  and  implementing  program  for  <.he  design,  develop- 
ment, test,  evaluation,  production  engineering,  standardization  and  basic 
design  engineering  support  for  tactical  digital  processor  and  related 
software. 

The  Division  of  the  Avionics  Division  established  the  Computer  and 
Software  Branch  (AIR-5331)  to  carry  out  the  management  responsibility. 

NAVAIRINST  5230.5 

This  NAVAIR  instruction  sets  forth  the  responsibility  and  requirements 
for  preparation  of  Software  Life  Cycle  Management  Plans  (SLCMP) . The 
SLCMP  for  a major  NAVAIR  weapon  system  more  than  adequately  satisfies 
the  DODD  5000.29  policy  requirement  of  paragraph  V.D.,  for  a computer 
resource  plan.  The  SLCMP  requires  that  the  complete  life  cycle  be  addressed 
for  the  operational  software  of  the  weapon  system  and  that  the  plan  be 
originated  prior  to  the  Request  for  Proposal  (RFP)  for  full  scale  development 
and  shall  be  kept  current  thereafter  throughout  the  life  cycle  of  the 
weapon  system  (29:1).  Enclosure  (1)  to  the  NAVAIR  instruction  sets  forth 
in  thirty  five  pages  the  format  and  content  requirement  for  a SLCMP. 
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NAVAIRINST  5420.24 


This  NAVAIR  instruction  established  the  Naval  Air  Software  Management 
Advisory  Committee  (NASMAC)  on  30  January  1975  to  address  the  establish- 
ment of  software  standards,  specifications,  management  manuals  and 
instructions  (39) . NASMAC  is  chaired  by  a NAVAIR  representative  and 
utilizes  two  software  experts  from  each  of  six  Navy  field  activities 
which  are  the  Naval  Air  Development  Center,  Naval  Avionics  Facility 
Indianapolis,  Naval  Air  Test  Center,  Naval  Missile  Center,  Naval  Surface 
Weapons  Center  Dahlgren,  and  Naval  Weapons  Center.  These  activities  are 
currently  assisting  NAVAIR  in  developing  and/or  supporting  NAVAIR  weapon 
system  software.  This  committee  participated  in  the  writing  of  NAVAIR 
instruction  5230.5  and  the  draft  NAVAIRINSTS  discussed  in  the  following 
subsection. 


Draft  NAVAIRINSTs 

The  Computer  and  Software  Branch  (AIR-5331)  is  preparing  two  new 
software  related  NAVAIR  instructions.  One  instruction  will  establish 
Software  Change  Review  Boards  (SCRB).  The  purpose  of  a weapon  system 
SCRB  is  to  consolidate  all  software  changes  which  will  be  issued  in  the 
next  fleet  issue  tape  and  prepare  a Software  Engineering  Change  Proposal 
(SECP)  for  processing  through  the  NAVAIR  Configuration  Change  Board  (CCB) . 
The  Program  Manager  established  the  SCRB  Chairman.  The  members  of  the 
SCRB  will  include  members  from  the  acquisition,  logistic,  test  and 
evaluation  committees,  Navy  field  activities,  fleet  major  command  soft- 
ware representative  and  operation  test  and  evaluation  force  representatives. 
The  SCRB  serves  as  a management  discipline  to  exercise  configuration 
control  over  weapon  system  tactical  digital  processor  software  and  related 


support  software  (38:1).  The  SCRB  in  conjunction  with  the  existing 
NAVAIR  CCB  will  satisfy  the  policy  requirement  of  paragraph  V,C.  of 
DODD  5000.29  for  configuration  management  of  computer  resources  (12:2). 
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The  second  instruction  that  is  being  prepared  is  the  NAVAIR  Software 
Management  Manual  (26).  The  manual  will  set  forth  guidance  similiar  to 
that  found  in  AFR  800-14,  Volume  I,  and  will  be  organized  to  follow  the 
elements  set  forth  in  the  newly  promulgated  NAVAIR  SLCMP  instruction  (29). 
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SECTION  V 


ANALYSIS  OF  EXISTING  SOFTWARE  POLICY  AND 
GUIDANCE  DOCUMENTS  WITHIN  AIR  FORCE, 

ARMY,  AND  NAVY 

Air  Force 

The  Air  Force  has  several  regulations,  pamphlets,  manuals,  and  military 
standards  which  address  Acquisition  Management.  The  Air  Force  Systems 
Command  Pamphlet  800-3,  "A  Guide  For  Program  Management",  is  similiar  to 
NAVAIR's  AR-59B.  Two  differences,  however,  stand  out.  AFSC  Pamphlet 
800-3  was  promulgated  on  9 April  1976  and  adequately  sets  forth  the 
acquisitions  phases  as  currently  conducted  and  provides  valuable  guidance 
to  an  Air  Force  program  manager  where  as  AR-59B  promulgated  on  1 May  1972 
does  not  provide  the  necessary  up-to-date  guidance  the  NAVAIR  program 
manager  needs.  Secondly,  AFSC  Pamphlet  800-3  gives  the  program  manager 
guidance  for  computer  resources  where  AR-59B  does  not.  As  part  of  the 
validation  phase,  AFSC  Pamphlet  800-3  states  that  (1)  computer  program 
specifications  should  be  included  as  contract  requirements  (3:3-7)  and 
(2)  that  the  program  manager  should  consider  the  AFR  800-14  computer 
resources  requirements  in  planning  the  full  scale  development  contract 
work  statement  tasks  (3:3-8). 

The  Air  Force  AFR  800-14,  Volume  I,  "Management  of  Computer  Resources 
in  Systems",  dated  12  September  1975,  establishes  policy  for  the  acquisi- 
tion and  support  of  embedded  digital  computers  and  computer  programs.  Its 
objective  is  to  insure  that  computer  resources  in  systems  are  planned, 
developed,  acquired,  employed,  and  supported  to  effectively,  efficiently, 


and  economically  accomplish  Air  Force  assigned  missions  (1:1).  The 
regulation  sets  forth  ten  (10)  areas  which  must  be  provided  for  in  the 
Program  Management  Plans  (PMPs)  and  directs  the  program  managers  to 
provide  management  and  technical  emphasis  to  them.  Some  of  the  more  import- 
ant areas  addressed  are  establishing  technical  and  managerial  expertise  for 
computer  resources  preferably  in  the  program  office,  providing  sufficient 
computer  equipment  capacity  and  flexible  computer  program  design  during 
the  planning  and  development  phases  to  provide  growth  and  ease  of  modifi- 
cation and  maintenance  throughout  the  system  life,  providing  for  the 
timely  preparation  of  support  plans,  establishing  comprehensive  tests  of 
computer  equipment  and  verification  and  validation  of  computer  programs, 
treating  the  computer  equipment  and  computer  programs  as  configuration 
items,  utilizing  work  breakdown  structures  to  facilitate  indentif ication 
of  computer  resource  costs,  and  covering  computer  equipment  and  computer 
programs  during  the  conduct  of  system  design  reviews,  audits,  and  manage- 
ment assessments  (1:2).  The  DODD  5000.29  policy  closely  alines  with  the 
above.  To  date  NAVAIR  has  not  received  the  above  type  of  policy  guidance 
from  the  NMC  nor  does  NAVAIR  have  similiar  policy  guidance  in  the  form  of 
NAVAIR  instructions. 

The  Air  Force  AFR  800-14,  Volume  II,  "Acquisition  and  Support 
Procedures  for  Computer  Resources  in  System",  dated  26  September  1976, 
consolidates  procedures  that  apply  when  implementing  the  policies  of 
AFR  800-14,  Volume  I and  other  related  Air  Force  publications  as  they 
pertain  to  the  acquisition  and  support  of  computer  resources  (2:1).  The 
regulation  does  an  excellent  job  of  relating  the  computer  resources 
acquisition  process  to  the  existing  Air  Force  structure  orginally  designed 
for  acquisition  of  hardware.  Detail  procedures  are  set  forth  such  that 


they  can  be  tailored  to  the  individual  needs  of  a given  program.  Chapters 
are  set  forth  which  address  areas  such  as  planning,  engineering  management, 
testing,  configuration  management,  documentation,  contractual  require- 
ments, turnover  and  transfer,  and  support.  To  date  NAVAIR  has  nothing 
like  this;  however  a NAVAIR  Software  Management  Manual  is  in  preparation 
and  will  address  similiar  areas. 

The  Air  Force  has  several  service  perculiar  military  standards  which 
do  set  forth  requirements  for  computer  resources  and  are  approved  for  use 
by  the  Department  of  the  Air  Force.  MIL-STD-483  (USAF)  sets  forth 
configuration  practices  for  computer  programs  (21).  The  standard  expands 
upon  the  B5  and  CS  type  software  specifications  set  forth  in  MIL-STD-490 
(22)  and  provides  for  Part  I and  Part  II  specifications.  Ironically, 
these  specifications  are  very  similiar  to  what  the  Navy's  SECNAVINST 
3560.1  sets  forth  as  Program  Performance  Specifications  and  Program  Design 
Specifications  (41).  It  is  no  wonder  the  DOD  contractors  are  complaining 
about  how  the  services  procure  software.  All  three  documents  (MIL-STD- 
483,  MIL-STD-490,  and  SECNAVINST  3560.1)  essentially  provide  for  the 
same  types  of  specifications  in  slightly  different  formats.  MIL-STD-483 
(USAF)  expands  upon  MIL-STD-480  and  provide  Air  Force  perculiar  forms 
and  procedures  for  configuration  control  of  computer  program  configuration 
items  whereas  MIL-STD-480  really  doesn’t  adequately  address  this  problem 
(20).  MIL-STD-499A  (USAF)  sets  forth  the  practices  for  engineering 
management  (23).  It  ties  together  MIL-STD-483  (USAF)  and  MIL-STD-1521 
(USAF)  and  provides  a framework  for  the  management  of  the  engineering  and 
technical  effort  necessary  to  transform  a military  requirement  into  an 
operational  system.  MIL-STD-1521  (USAF)  sets  forth  the  requirements  for 


25 


conduction  of  technical  reviews  and  audits  (24).  It  provides  for  computer 
resources  and  details  the  areas  which  should  be  examined  during  the  reviews 
and  audits.  It  was  published  on  1 September  1972  and  adequately  addresses 
computer  resources  for  that  time  period.  In  light  of  DODD  5000.29,  it 
should  be  updated.  The  Navy  is  attempting  to  consolidate  the  above 
Air  Force  military  standards  into  its  draft  MIL-STD-1697.  This  will  be 
discussed  later  in  the  report. 

In  summary  the  Air  Force  does  have  the  managment  of  computer  resources 
fairly  well  covered  and  comes  closest  of  any  of  the  services  to  meeting 
DODD  5000.29. 

Army 

The  Army  AMC  Pamphlet  70-4,  "Research  and  Development,  Software 
Acquisition,  a Guide  for  the  Material  Developer",  dated  September  1974, 
sets  forth  a guide  book  which  is  designed  to  instruct  Army  Material 
Command,  now  DARCOM  (Development  and  Readiness  Command),  acquirers  in 
the  procurement  of  computer  resources  (4).  It  sets  forth  the  traditional 
pitfalls  in  software  acquisition,  points  out  relevant  guidance  documentation, 
and  offers  alternatives  and  tradeoffs  which  may  be  adapted  to  the 
individual  program.  An  interesting  point  brought  out  is  that  the  Army 
personnel  involved  in  software  procurement  should  be  aware  of  the 
numerious  regulations  and  exhibits  that  have  been  published  by  the  Air 
Force  and  the  Navy  over  the  past  ten  years  which  cover  the  acquisition  of 
software  systems.  AMC  Pamphlet  70-4  presents  many  of  the  Air  Force 
military  standards  and  provides  guidance  similiar  to  the  Air  Force.  It 
does  provide  a model  statement  of  work  which  can  be  tailored  for  a given 
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software  contract.  Appendix  C to  AMC  Pamphlet  70-4  provides  in  full 
many  of  the  standard  Data  Item  Descriptions,  DD  Form  1664,  that  have 
been  prepared  by  the  Air  Force  for  use  in  contracts  requiring  the  delivery 
of  software  data. 


On  11  August  1971  the  Chief  of  Naval  Material  established,  by 
NAVMATINST  5230.5,  the  Tactical  Digital  Systems  Office  (TADSO),  MAT-09Y, 
to  be  responsible  for  ensuring  standardization,  configuration  and  inter- 
face management,  and  compatibility  of  tactical  automated  data  systems, 
equipment,  and  software  (33:1).  TADSO  is  responsible  for  formulating 
overall  Naval  Material  Command  (NMC)  policy  for  tactical  weapon  system 
computer  resources  which  is  then  implemented  by  the  Navy  Systems  Commands 
(NAVAIR,  NAVELEX,  and  NAVSEA).  TADSO  does  not  exercise  direct  control 
of  funds  but  does  possess  approval/disapproval  authority  of  the  System 
Commands/program  managers  use  of  funds  for  computer  resources  and  does 
participate  in  NMC  budgeting,  programming,  reprogramming  and  other 
computer  resources  related  program  budget  actions. 

TADSO  issues  TADSTANDs  (Tactical  Digital  Standards)  in  lieu  of 
NAVMATINSTs  to  promulgate  NMC  policy  in  most  instances.  This  is  somewhat 
confusing  since  some  are  applicable  to  ships  and  aircrafts  and  others 
are  only  applicable  to  one  or  the  other.  NAVAIR  has  been  attempting  to 
get  TADSO  to  do  away  with  TADSTANDSs  and  consolidate  the  policy  in 
NAVMATINSTs.  With  the  effort  forthcoming  to  implement  DODD  5000.29 
hopefully  this  will  be  done.  There  are  three  TADSTANDs  in  particular 
which  contain  requirements  that  impact  NAVAIR.  TADSTAND  2,  Revision  1, 
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sets  forth  the  requirement  for  the  standard  specification  of  tactical 
digital  computer  program  documentation  in  accordance  with  SECNAVINST 
3560.1  (42).  TADSTAND  4 sets  forth  standard  definitions  of  tactical 
digital  systems  (43).  TADSTAND  5 sets  forth  the  standard  reserve  capacity 
requirements  for  digital  combat  system  processors  which  is  at  least  20% 
reserve  for  installed  memory,  processor  time,  and  input/output  channels 
during  the  development  phase  (44). 

TADSO  has  promulgated  two  additional  documents  for  use  by  the  Navy 
System  Commands.  One.  is  the  Navy  and  Marine  Corps  Tactical  Digital 
Equipment  Catalogue  which  contains  a list  of  the  current  Navy  inventory 
of  digitial  processors,  peripheral  devices,  and  displays  (35).  The 
catalogue  gives  certain  characteristics  of  the  equipment  and  is  to  be 
used  by  the  program  manager  to  determine  what  computer  equipment  is 
available  for  use  in  his  system  without  having  to  develop  his  own.  The 
second  document  which  has  been  issued  is  the  U. S.  Navy  Tactical  Digital 
Systems  Tactical  Data  Systems  Glossary  and  is  to  be  used  in  the  prepar- 
ation of  computer  program  documentation  (45). 

TADSO  is  in  the  process  of  having  a Software  Management  Manual 
prepared  but  this  was  not  available  to  the  author  for  review.  It  will 
apparently  attempt  to  implement  for  the  Navy  what  AFSC  Pamphlet  800-14, 
Volumes  I and  II,  did  for  the  Air  Force.  TADSO  has  also  prepared  a 
draft  Navy  military  standard,  MIL-STD-1697 , which  will  be  the  Navy 
Tactical  Software  Development  standard  (25).  It  will  provide  require- 
ments similiar  to  that  provided  in  MIL-STD-483  (USAF),  MIL-499A  (USAF) , 
and  MIL-STD-1521  (USAF).  All  the  computer  program  documentation  standards 
now  contained  in  SECNAVINST  3560.1  will  be  rewritten  in  the  form  of 
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standard  Data  Item  Descriptions,  DD  Form  1664,  and  will  become  an 
appendix  to  the  new  military  standard.  This  will  more  closely  aline  the 
Navy  with  the  required  DOD  data  procurement  policy.  The  military  standard 
when  finalized  will  certainly  aid  the  Navy  in  the  management  of  computer 
resources. 

NAVMATINST  5200. 27A,  prepared  by  TADSO,  sets  forth  the  procedures  for 
transfer  of  Navy  tactical  digital  system  software  responsibility  from 
the  developing  activity  to  the  program  mainline  activity  (32:1).  The 
instruction,  dated  18  April  1973,  required  that  the  planning  be  included 
in  the  Integrated  Logistics  Support  Plan  (ILSP)  or  if  no  ILSP  existed,  a 
Software  Life  Cycle  Management  Plan  (SLCMP)  was  to  be  generated.  The 
plan  is  to  include  the  major  milestones  required  to  achieve  an  orderly 
transfer,  the  resources  required  (funds,  equipment,  and  people),  docu- 
mentation requests,  and  life  cycle  funding  projection.  This  instruction 
basically  satisfies  the  policy  requirements  of  paragraph  V.D.  of  DODD 
5000.29  for  computer  resources  life  cycle  planning.  It  should,  however, 
be  updated  to  include  the  requirement  for  the  computer  resource  plan  prior 
to  DSARC  II. 

SECNAVINST  3560.1  sets  forth  the  Department  of  the  Navy  Tactical 
Digital  Systems  Documentation  Standards  and  provides  a format  to  which 
computer  program  documentation  is  to  be  prepared  (41).  It  includes 
specifications  for  the  system,  functional,  interface,  and  program  levels 
of  a software  system.  It  specifies  test  plans,  test  specifications,  and 
test  reports  as  well  as  operator's  manuals.  It  provides  for  the  program 
package  itself  which  is  the  machine  and  human  readable  forms  of  the  actual 
computer  program.  Prior  to  the  issuance  of  SECNAVINST  3560.1  in  August 
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of  1974,  Weapon  Specification  WS-8506  (NAVORD) , Revision  1,  set  forth  the 
requirement  for  digital  computer  program  documentation  (47).  WS-8506  is 

a subset  of  SECNAVINST  3560.1  and  for  small  system  provided  adequate 
documentation. 

The  Navy  then  has  had  good  standards  to  which  computer  program 
documentation  was  procured.  What  the  Navy  lacked  was  a policy  guidance 
mechanism  to  implement  what  the  people  at  the  working  level  were  attempting 
to  do.  The  issuance  of  DODD  5000.29  should  help  solve  this  problem.  TADSO 
does  have  members  on  the  DOD  Software  Steering  Committee  and  were  active 
in  the  support  of  the  issuance  of  DODD  5000.29. 

Tri-Service  Documents 

One  of  the  main  reasons  for  the  promulgation  of  DODD  5000.29  is  the 
lack  of  standardization  among  the  services  in  the  area  of  management  of 
computer  resources.  MIL-STD-490  sets  forth  the  format  for  military 
specification  and  its  B5  and  C5  type  formats  are  for  computer  program 
specification  (22).  How  then  did  the  Air  Force  arrive  at  its  Part  I and 
Part  II  computer  program  specifications  found  in  MIL-STD-483  (USAF)  and 
the  Navy  arrive  at  its  computer  program  specifications  found  in  SECNAVINST 
3560.1  (41)? 

The  answer  lies  in  the  interruption  of  MIL-S-83490  (19).  MIL-S-83490, 

Specifications,  Types  and  Forms,  is  mandatory  for  use  by  all  Departments 
and  Agencies  of  the  DOD  and  prescribes  general  requirements  for  the  prepar- 
ation of  specifications.  It  essentially  sets  forth  the  Type  A,  B,  C,  D,  and  E 
specifications  as  described  in  MIL-STD-490,  "Specification  Practices". 

It  does  enable  the  procuring  activity  to  specify  the  form  of  the 
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specification;  that  is  Form  la,  lb,  or  2.  Form  la  specification  conforms 
to  MIL-STD-490  in  all  details.  Form  lb  conforms  to  MIL-STD-490  except 
that  not  all  element  of  a MIL-STD-490  specification  need  apply,  and 
Form  2 is  a specification  to  commerical  practices  with  supplemented 
military  requirements.  This  capability  to  select  the  form  of  a specifi- 
cation thus  allowed  the  Air  Force  and  the  Navy  to  establish  similiar  but 
different  computer  program  specification  requirement. 

If  a contractor  does  work  for  more  than  one  service,  he  will  have 
similiar  but  different  procedures  for  the  generation  of  software  data  which 
results  in  unnecessary  costs.  If  DODD  5000.29  can  force  the  services  to 
standardize  their  requirements,  the  DOD  contractors  will  be  in  a position 
to  more  easily  and  cheaply  provide  the  software  data  which  DOD  procures. 
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SECTION  VI 


CONCLUSIONS  AND  RECOMMENDATIONS 
Conclusions 

The  complexity  of- today's  aircraft  weapon  systems  has  driven  the  Air 
Force  and  NAVAIR  to  the  point  of  being  highly  dependent  on  digital  computers. 
NAVSEA  is  in  the  same  position  with  ship  board  systems  being  forced  to  put 
many  highly  sophisticated  weapon  systems  aboard  ships  wide  limited  space. 
Fortunately  NAVSEA  has  for  the  most  part  standardized  its  computer  hardware 
and  support  software.  All  services  have  similiar  problems  in  the  procure- 
ment of  computer  programs.  The  Air  Force  has  a better  system  for  configur- 
ation management  of  computer  programs.  The  Navy  has  a more  indepth 
documentation  requirement  for  computer  program  deliverables. 

The  analysis  of  the  current  status  of  computer  resources  related 
guidance  documents  within  the  Service  Components  revealed  that  the  Air 
Force  has  in  existance  two  documents  which  closely  approach  compliance 
with  DODD  5000.29.  AFSC  Pamphlet  800-3  and  AFR  800-14  set  forth  policy 
and  guidance  to  Air  Force  program  managers  for  the  management  of  computer 
resources  and  the  tailoring  of  existing  Air  Force  documents  and  military 
standards.  The  Navy  has  no  existing  documents  which  adequately  provide  the 
same  type  of  policy  and  guidance  for  its  program  managers.  The  program 
manager's  PROMPT  Guide  at  NAVAIR  was  issued  in  May  1972  and  is  in  need  of 
being  updated.  The  Army  appears  to  rely  on  Air  Force  military  standards 
and  tailor  them  as  required. 
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DODD  5000.29,  if  implemented  properly,  should  help  solve  the  problem. 
The  two  most  serious  computer  resources  problems,  which  hopefully  it  will 
solve,  are  the  lack  of  trained  personnel  and  the  lack  of  a tri-service 
effort  in  attacking  the  problem.  From  a review  of  the  DOD  Defense  System 
Software  Management  Plan,  the  author  estimates  that  it  will  take  from 
3 to  5 years  to  resolve  the  management  problems  and  :>  to  10  years  to 
establish  and  benefit  from  the  proposed  R&D  technology  effort.  With  the 
rate  at  which  technology  is  doubling  in  the  country,  the  author  questions 
whether  or  not  the  saying,  "the  faster  1 go  the  further  behind  I get", 
is  in  fact  not  true? 

What  then  should  NAVAIR  do  in  light  of  the  current  situation? 

Recemmendations 

Several  alternatives  are  available  to  NAVAIR.  NAVAIR  could  standby 
and  wait  for  implementing  instructions  from  KMC  and  live  within  its 
existing  NAVAIR  documents  for  the  time  being.  NAVAIR  could  decide  to 
depend  more  heavily  on  its  prime  contractors  and  give  them  only  broad 
requirements  to  satisfy  DODD  5000.29.  Neither  of  these  alternatives 
provide  a satisfactory  solution  to  the  rising  cost  associated  with 
today's  highly  digitized  weapon  systems.  The  author's  recommended  solution 
is  a two  front  attack  on  the  problem. 

The  first  problem  to  be  solved  is  that  of  educating  NAVAIR  program 
managers  and  providing  them  with  current  acquisition  guidance  similiar 
to  that  provided  in  AFSC  Pamphlet  800-3  and  AFR  800-14.  NAVAIR's  AR-59B 
should  be  updated  and  promulgated  in  the  form  of  a NAVAIR  instruction. 

The  NAVAIR  program  managers  should  have  available  to  them  personnel. 
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either  from  the  functional  group  at  NAVAIR  or  a Navy  field  activity,  who 
can  realistically  support  them  in  the  management  of  computer  resources 
and  the  execution  of  related  contracts. 

The  second  problem  is  to  complete  the  preparation  of  the  two  inprocess 
computer  resources  related  NAVAIR  instructions.  The  newly  promulgated 
SLCMP  instruction  provides  the  framework  in  which  the  NAVAIR  program 
manager  may  plan  for  and  identify  the  critical  computer  resources  required 
to  adequately  support  his  weapon  system  throughout  its  life  cycle.  The 
SLCMP  instruction  does  not  provide  the  guidelines  and  lessons  learned  on 
which  the  program  manager  can  make  the  necessary  tradeoffs  and  critical 
decisions  required.  The  inprocess  NAVAIR  Software  Management  Manual  will 
provide  this  guidance.  NAVAIR  should  review  the  APL  and  MITRE  reports 
and  the  Air  Force  documents  and  finalize  its  manual.  With  a concentrated 
effort,  the  instruction  could  be  completed  and  signed  within  six  months. 
The  SCRB  instruction  appears  almost  ready  for  signature. 

If  NAVAIR  completes  the  above  documents,  all  of  the  policy  set  forth 
in  DODD  5000.29  will  effectively  have  been  implemented  with  the  exception 
of  personnel  training  programs  and  software  R&D  efforts.  These  areas 
should  be  coordinated  with  NMC  with  the  proposed  solutions  coming  from 


the  DOD  or  SECNAV  level. 
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